Anonymous trading system

ABSTRACT

A computerized system associates each arbitrator computer of a plurality of arbitrator computers with a different one of a plurality of credit manager computers, wherein each associated arbitrator computer of the plurality of arbitrator computers is located geographically more proximate to an associated trader workstation of a plurality of trader workstations than others of the plurality of arbitrator computers, and locates the different one of the plurality of credit manager computers in a same location as the associated arbitrator computer so as to provide low network latency between a time an electronic trade order is transmitted from the associated trader workstation and received by the associated arbitrator computer and a time that a match is made by the associated arbitrator computer.

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application is a continuation under 37 C.F.R. 1.53(b) ofU.S. patent application Ser. No. 17/376,741, filed Jul. 15, 2021, nowU.S. Pat. No. ______, which is a continuation under 37 C.F.R. 1.53(b) ofU.S. patent application Ser. No. 13/212,524, filed Aug. 18, 2011, nowU.S. Pat. No. 11,100,577, which claims benefit under 35 U.S.C. § 119(e)to U.S. Provisional application No. 61/375,352, filed Aug. 20, 2010, theentirety of all of which are incorporated herein by reference.

FIELD OF THE INVENTION

This invention relates to anonymous trading systems for trading fungibleinstruments, and in particular computerised anonymous trading systems.

BACKGROUND OF THE INVENTION

Anonymous trading systems are used widely to trade fungible instruments,particularly financial instruments such as foreign exchange (FX)products. These systems have been very successful and are used for themajority of transactions in some instruments, for example FX spot.

As their name suggests, anonymous trading systems do not allow theparticipants to know the identity of potential counterparties to atransaction until the trade has been confirmed. One known systemdescribed in European patent application No. EP-A-625275 and illustratedin FIG. 1A, requires traders to input quotes in the forms of bids andoffers into the system via their trader terminals or workstations. Thesequotes are matched with other quotes in the system by a matching engineor arbitrator. Where a match is found, a deal will be executed betweenthe parties, once it has been established that each party has sufficientcredit with the other for the deal. A market distributor is arrangedbetween the arbitrator and a bank node, at which is stored a creditmatrix indicative of credit assigned by a bank to all counterparties onthe system. The market distributor is responsible for constructing amarket view for each trading floor based on their credit as representedby the binary credit matrix stored at the market distributor. Thus,traders at a given trading floor are only shown quotes input into thesystem by parties with whom they have credit. The actual credit limitsare stored at bank nodes in the EP A 625275 system. In other words, amarket distributor is located at the same location as the trading floorwith which each is associated. The market distributors must communicatewith other market distributors in order to update the credit matrix. Ascan be seen clearly from FIG. 1A, this is done through communication viaarbitrators. In practice, the arbitrators, of which there are threeglobally, are located at the main centres of trade: New York, London andTokyo. This ensures fair matching at these centres of trade as messagesrelated to matching need only travel from local traders to their localarbitrator. Otherwise, the latency in electronic messages travellingaround the globe can have a detrimental impact on orders being matched.Furthermore, in this arrangement, as the communications between marketdistributors (of which there are currently 64 globally) regarding thecredit matrix is via at least one arbitrator it takes some time forthese messages to be transmitted. This increases deal times.

Rather than waiting for the matching engine to match visible ordersinput into the system, traders can input invisible hit and take orderswhich are an offer to sell or buy a quote at the price and for theamount of the offer.

Once a deal has been concluded, details of the trade, including theidentity of the parties and the price at which the deal was concluded,are distributed to all trading floors. Thus, the system is no longeranonymous once deals have been completed.

As illustrated in FIG. 1B, Reuters' published European patentapplication No. EP 399 850, EP 407 026, and EP 411 748 discloses anotherautomated matching system for anonymous trading of foreign currencies(or other financial instruments) in which a single host computer 20maintains a central database consisting of all the trading instrumentsavailable for trade, credit information, and the various bids and offersthat are present throughout the system. The host computer uses theinformation in its central database to match active bids and offers (aswell as executing any transitory “hit bid” and “take offer”transactions) based on matching criteria which include the grosscounterparty credit limit between counterparties to a potential matchingtransaction, price, and available quantity. The host computer blockscompletion of an otherwise eligible matching transaction between a givenpair of potential counterparties when the transaction has an associatedvalue in excess of the applicable gross credit limit. In this system,the various client site computers (keystations) merely maintain anddisplay a restricted subset of the information available at the centralcomputer, such as a predetermined number of the best bids and offers,and communicate credit and other transaction-oriented information to thesingle host computer for execution. However, in an attempt to preservethe anonymity of the parties, the client sites do not have access to anycredit limits set by their possible counterparties, or even to theidentification of any other party to a particular transaction untilafter a transaction has been completed.

Thus, in this system, confidential counterparty credit limit data ismaintained in real time and utilized as part of the trade matchingprocess by a central host computer. As a consequence, each client sitehas no way to determine, prior to committing to buy or sell at adisplayed price from one or more anonymous counterparties, whether it isin fact eligible to respond to any of the bids or offers currently beingdisplayed. The client site is connected to the central host computer bytelecommunication lines; the host computer is not under the directcontrol of the party providing the confidential credit limit data andthus provides potential opportunities for unauthorized access to thecredit information, even though the host computer does not utilize thecredit information until a match has been found between a Buyer and aSeller.

Consequently, unless he attempts to execute a trade at the best pricecurrently displayed on his screen, a trader using the prior art Reutersanonymous matching system has no way of knowing whether he has creditwith, and is willing to extend credit to, the anonymous counterpartyoffering (bidding) the best price currently displayed on his screen andthus whether any attempt to buy or sell at the displayed price will besubsequently invalidated by the system for lack of such credit.

These systems have been most useful for trading regular amounts of aninstrument. However, they are not ideal for trading large amountsoutside the regular trading range. If one considers the example of FXSpot a typical deal amount is between $1M and $5M ($1 to 5 million). Ifa bank needs to trade a large amount, for example $50M, it is veryunlikely to find a single party willing to trade the whole amount.Instead, a number of separate trades, each probably in the range of $1Mto $5M will be concluded. While this order is being filled, the traders'screen will show details of the deals so far concluded. They will see astring of deals all showing the party with the $50M quote on the sameside of the deal. The market will conclude that there is a party whoneeds to buy or sell a large amount of currency and adjust their pricesaccordingly to the detriment of the party with the large amount to buyor sell.

There is a need for a system which facilitates the trading of largeamounts without impacting on the market. This may be without beingrestricted to a specified time throughout the trading day.

There is also a need for a system that reduces communication betweenbank nodes in the trading system arrangement described in EP-A-625275 asthis increases deal times and there is a desire to decrease them.Aspects of the present invention aim to address this technical problem.

BRIEF SUMMARY OF THE INVENTION

In one aspect of the present invention, there is provided a computerisedmethod of trading a fungible instrument, the method comprising:receiving orders from traders for a fungible instrument, the orders eachcomprising an amount of the fungible instrument to buy or sell, but noprice; matching the orders; and fixing the price of matched orders at aprice based on an outside source at a predetermined time.

Advantageously, this method facilitates the trading of large amounts ofan instrument without impacting on the market.

Preferably, the outside source is a source of prices not provided by thetrading system or from traders trading on the trading system.Preferably, orders on the system are pre-screened for credit withprospective counterparties on the system.

In one embodiment, the price is fixed at periodic intervals. Theperiodic intervals may be throughout a trading day, preferably twointervals throughout a trading day per outside source. Different outsidesources may be used for fixing the price. Each outside source may befixed once, twice or more per trading day. For example, between once andten times per trading day. Traders trading on the system may include thetime of the price fixing when an outside source fixes the price at morethan one interval throughout the trading day. The traders order may alsoinclude the outside source that they wish to use for the price fixing.

Preferably, an indication is given to a trader when a deadline forreceiving orders is near. Preferably, an indication is given to a traderat a deadline for receiving orders.

In one embodiment, the price of matched orders is fixed at the same timeorders are matched. Advantageously, this facilitates the trading oflarge amounts without impacting on the market and without beingrestricted to specified time throughout the trading day. In thisembodiment, traders do not specify the time of the price fixing in theirorder, as the order is always executed immediately.

Preferably, after a price of a matched order has been fixed, a tradertriggers the release of a deal ticket reflecting the executed order.

Preferably, a deal ticket is issued for each matched order. Preferably,the deal ticket for each matched order is issued, at the latest, at theend of a trading day. Advantageously, this arrangement provides acomplete audit trail.

A trader may enter orders to buy and sell the same fungible instrument.This arrangement allows traders to find out market sentiment.

In another aspect of the present invention, there is providedcomputerised trading system, the computerised trading system comprising:one or more computers arranged on a network, the one or more computersbeing arranged to: receive orders from parties for a fungibleinstrument, the orders each comprising an amount of the fungibleinstrument to buy or sell, but no price; match the orders; and fix theprice of matched orders at a price based on an outside source at apredetermined time

In a further aspect of the present invention there is provided, acomputerised trading system, the computerised trading system comprising:a plurality of arbitrator computers configured to match orders betweencounterparties in the system, each order comprising an amount of afungible instrument to buy or sell; wherein a credit manager computer isassociated with each arbitrator computer, each credit manager computerbeing configured to determine whether a predetermined level of credit isavailable between counterparties before orders between counterpartiesare matched.

Advantageously, each arbitrator has a different credit managerassociated with it.

In one embodiment, the predetermined level of credit available betweencounterparties is based on the fungible instrument being traded betweencounterparties. In another embodiment, the predetermined level of creditavailable between counterparties is based on the institutions of whichthe counterparties are a part.

Preferably, each arbitrator computer and associated credit managercomputer is located at substantially the same location. Each arbitratorcomputer and associated credit manager computer may be located in thesame building. Each arbitrator computer and associated credit managercomputer may be located in the same city. Each arbitrator computer andassociated credit manager computer may be located in the same country.Advantageously, these arrangements provide low deal times.

Preferably, the computerised trading system further comprises aplurality of market access node computers, each market access nodecomputer being associated with a trading floor and being configured tostore credit limits for the trading floor with which it is associated.

Preferably, the market access node computers are located remote from thearbitrator computers and credit managers.

Preferably, the orders at each arbitrator are from traders in a regionin which the arbitrator is located.

According to another aspect of the invention, there is provided acomputerised method of trading a fungible instrument, the methodcomprising: a plurality of arbitrator computers each matching ordersbetween counterparties in the system, each order comprising an amount ofa fungible instrument to buy or sell; and a credit manager computerassociated with each arbitrator computer determining whether apredetermined level of credit is available between counterparties beforeorders between counterparties are matched.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the invention will now be described, by way of example,and with reference to the accompanying drawings, in which:

FIG. 1A is a schematic diagram of a known computerised trading system;

FIG. 1B is a schematic diagram of another known computerised tradingsystem;

FIG. 2 is a timeline to illustrate an example embodiment of the presentinvention;

FIGS. 3 to 14 are portions of a trader's computer screen display toillustrate example embodiments of the present invention;

FIG. 15 is a table to illustrate an example embodiment of the presentinvention;

FIG. 16 is a portion of a trader's computer screen display to illustratean example embodiment of the present invention;

FIG. 17 is a table to illustrate an example embodiment of the presentinvention;

FIGS. 18 to 20 are portions of a trader's computer screen display toillustrate example embodiments of the present invention;

FIG. 21A is a schematic diagram of a system embodying the presentinvention;

FIG. 21B is a schematic diagram of an embodiment of the presentinvention;

FIG. 22 is a table to illustrate an example embodiment of the presentinvention; and

FIGS. 23 to 35 are schematic diagrams of embodiments of the presentinvention.

DETAILED DESCRIPTION OF THE INVENTION

Referring to FIG. 2 onwards, on the computerised system embodying theinvention, orders are received from parties for a fungible instrument.The orders each comprise an amount of the fungible instrument to buy orsell, but no price. Orders are matched at a price based on an outsidesource at the time the orders are matched. Orders are submitted into thesystem rather than quotes. A quote requires both a price and a quantity(amount). Two different variations of the system are described: theso-called fix order system and the continuous matching system.

In the fix order system, the price of an order is set by an outsidesource at a predetermined time in the future and is then applied to thematched trades. Orders are matched and the price is set at thepredetermined time. In the continuous matching system, in contrast, aprice is placed immediately or as soon as offsetting orders are matched.There is no wait to fix the price until the designated fixing time.Although there may be a very short wait, based on how quickly the pricesfrom the outside stream of prices is updated. This may be of the orderof seconds or fractions of seconds. In both fix orders and continuousmatching, orders are entered into a dark pool, that is to say whereliquidity in the market is not displayed in order books. Prices are notset by the traders trading on the trading system.

Fixing Orders provide traders the capability to enter buy/sell customerorders that are to be executed at the ‘Fix Rate’. Fix orders are matched‘off-screen’, once an off-setting amount is detected. These amounts willbe matched and locked and completed once the fixing rate has beendetermined. The rate will be applied to the ticket at or directly afterthe ‘fixing time’. This arrangement has the advantage that it capturesthe fixing trades currently executed by the voice broker market byproviding traders the ability to match off-setting interest anonymously.

The price or rates to be used are typically an indicative rate of pricescurrently in the market, such as EBS Smoothed Rates or mid-rates derivedfrom a Reuters feed. The price used is, preferably, the mid-rate betweenthe buy and sell rates of the feed.

The fix order and continuous matching arrangements may be implemented,by way of example, on either of the known computer systems describedabove: the distributed architecture of EP 625275 or the centralisedarchitecture of EP 399850, EP 407026, and EP 411748. An alternativearchitecture using a computerised credit manager is described furtherbelow. The credit manager has a credit administrative informationfunction. The architecture is a variation of the architecture of thedistributed architecture of EP 625275 and includes a credit manager, ator associated with, each arbitrator. The credit manager stores creditinformation between traders. That is to say, credit information isstored away from bank nodes. This arrangement reduces the distancecredit messages must travel, thus reducing latency in the system. As aresult, deal times are reduced. This is discussed in more detail below.

Fix Orders

In Fix orders, buying interests and selling interests are submitted toan anonymous trading system with an amount, but no price. The orders arematched based on time in the market. The price is set by an outsidesource at a predetermined future time and is then applied to the matchedtrades. Each fix order contains a specified set of currency pairs and arange of time during which orders can be submitted. Preferably, therewill be multiple fixes available each trading day.

A fix order may be submitted by a trader on a computer trading terminalor workstation. The order may then be matched by the arbitrator (such asthat of EP 625275 described above), in segments, where credit existsbetween counterparties (the parties are pre-screened for credit betweenthem) or, in other words, there is bilateral credit. At the close oftrade, the unmatched portion of the fix order is cancelled by thetrading system. Shortly after fix time, when the price of the matchedorder is fixed, a fix rate or price will be sent by a news and ratesmanager (NRM) to the trading system for each currency pair contained inthe fix. The trading system applies the rates to all trades for eachcurrency pair in the fix. Deal tickets are generated for each of thetrades.

A fix order is assigned a two-character order type, “FX”. They have adefined and configurable set of currency pairs that can be tradedbetween the time trading opens (when order submission begins) and thetime it closes (when no further orders can be submitted). For example,as illustrated in FIG. 2 , trading for the WM fix begins at 09:58:30.Trading for the ECB fix begins at 12:13:30. Trading for the WM fixceases at 10:58:30. Trading for ECB Fix ceases at 13:13:30. The timebetween when trading begins and ceases is the trade period.

Below are the actions performed by the trading system at the events onthe timeline of FIG. 2 .

At trade open time, the quote panel 100 of FIG. 3 on the computerdisplay of a computer trading terminal is such that the order type ofFix Order 102 is activated (no longer grayed out) and a trader canselect the Fix Order on the drop-down menu 104. If the currency paircurrently selected by the trader is not available for a fix order thenthe order type of Fix Order remains deactivated (grayed out). The FixOrder option may also be disabled by a trader, in which case it willalso be grayed out. The enabling of Fix Order order type is agnostic ofthe day of the week. In the quote panel, towards the centre of thedisplay, shown enlarged, is the present bid 106 for inputting into themarket. Fix Order on the dropdown menu shall not be displayed if thetrader's floor is a professional trading community (PTC) trading floor.

The enlarged number 106, here 97, is only the least significant digitsof the price, known as the pips. Of course, for a Fix Order prices arenot entered, but only amounts. Hence, when the Fix Order order type isselected in the drop-down menu of FIG. 3 a panel is displayed, calledthe Fix Order Request Panel 200, which is illustrated in FIG. 4 .

As shown in FIG. 4 , the Fix Order Request Panel 200 on a display of atrader's computer terminal includes the currency pair 202 for the FixOrder in the upper left corner. The current Fix Offering 204, that is tosay the price source and the time (Fix Time) at which the price is to befixed, is displayed at the top center of the panel, after the words“Fix:”. In this example, the source of the Fix is “WM”, and the Fix Timeis 16:00 GMT (Greenwich Mean Time). If there is more than one FixOffering available at the current time, then the display allows a traderto select for which offering he wishes to enter an order. This is doneusing the Order Panel 200′ shown in FIG. 5 . In this panel, “Select Fix. . . ” 204′ appears in the location of the current Fix Offering at thetop center of the panel. To the right of the words “Select Fix”, is adownwardly pointing arrow 206. By clicking or selecting this arrow, thevarious Fix Offerings will be presented in a drop-down menu (not shown).This field is non-editable.

The drop-down icon 208 in the upper right-hand corner of the Fix OrderRequest Panel has the same functionality as the equivalent icon(obscured) in the Quote Panel of FIG. 3 , so that the order type beingentered can be changed by selecting the desired order type such as inthe drop-down menu of FIG. 3 . The drop down in the right upper corner,when selected, displays a list of order types. If the trader selects anew order type (non-Fix), then the Quote Panel for the selected ordertype is displayed.

In the middle of the panel of the Fix Order Request Panel of FIG. 4 ,are buy amount 210 and sell amount 212 fields in black boxes. They areblank filled (in FIG. 4 ), that is to say, they are not displaying anybuy or sell amount. The buy amount is the left-hand box and the sellamount is the right-hand box. A trader enters the amount to be bought orsold in the Fix Order in the appropriate box. In this example, themaximum Fix Buy and Fix Sell Amounts that can be entered for an orderare 999. The minimum trade size for an order is the Spot minimum tradesize, i.e., one million for Spot currency pairs. The increments of theBuy and Sell amounts are the standard increment for the currency pair.In the Fix Order Request Panel of FIG. 5 , a Buy Amount of 300 has beenentered by a trader.

At the bottom left-hand side of the Panel is a send button 214 (leftmostposition) and a quit button 216. Their functionality is discussed ingreater detail below.

If there is only a single Fix offering available at the current time,the initial focus is on the Buy Amount 210 and the Sell Amount 212 isgreyed out if the Bid button had been selected in the Price Panel andvice versa. If there is more than one Fix offering available at thecurrent time (Fix Order Request Panel of FIG. 5 displayed), the initialfocus is on the Fix box 204′ at the top center. Once a specific Fixoffering is selected by the trader, the focus shifts to either the BuyAmount or the Sell Amount depending upon whether the Bid or Offer buttonhad been selected in the Price Panel.

There is no carryover of amounts or prices from the Fix Order RequestPanel to any other panel.

For a single Fix offering (Fix Order Request panel of FIG. 4 ), if theBid button had been selected in the Price Panel, the tabbing sequencefor the Fix Order Request Panel is “Buy Amount” 210, “Send” 214, “Quit”216. For a single Fix offering, if the Offer button had been selected inthe Price Panel, the tabbing sequence for the Fix Order Request Panel is“Sell Amount” 212, “Send” 214, “Quit” 216. For multiple Fix offerings(Fix Order Request panel of FIG. 5 ), the Fix box 204′ at the top centeris the first in the tabbing sequence, followed by the sequencepreviously stated for Buy and Sell.

For the next subsequent order for the same currency pair as the previousFix Order, the format of the Order Request panel reverts to the lastnon-Fix order type.

Selecting or clicking the “Quit” button 216 closes the Fix Order Requestpanel 200, 200′ and the entered order is not processed. The focusreverts to the Price Panel for the specific currency pair.

If no Buy Amount 210 or Sell Amount 212 is entered in the Fix OrderRequest panel 200, 200′ and the “Send” button 214 is selected, an errormessage “Trade size can't be blank.” is displayed (not shown).

If the Buy Amount 210 is populated, and the trader decides to sellinstead of buy, then he must select the Offer button in the Price Panel(not shown) to enable the Sell Amount 212 field in the Fix Order RequestPanel 200, 200′. Then, the Buy Amount 210 is cleared by the tradingsystem. The same applies for a sell action changing to a buy action.

If the “Send” button 214 is selected after the Trade Close, an errormessage “Fix has closed” is displayed (not shown).

For a currency pair, multiple Buy and Sell Fix orders are permitted.

Both Buy and Sell pre-match Fix orders are permitted simultaneously formultiple currency pairs within a Fix. A buyer can enter buy and sellinterest at the same time. This allows a trader to see the marketsentiment by whether the buy or sell interest (or indeed both) is beinghit. This is important because as trading is in a “dark pool”, a tradercannot see the order book, and so he cannot see which orders are beinghit. In this way, he can see that there is interest in the pool.

When the “Send” button 214, on the Fix Order Request panel 200, 200′ ofFIGS. 4 and 5 , is selected for the first valid order, the order istransferred to a Fix Order Panel 300 of a display of a trader's computerterminal illustrated in FIG. 6 . The entered Fix order 302 is displayedfollowing the Fix header line 304. If the “Send” button 214 is selectedin the panel of FIG. 4 , the error message described above of “Tradesize can't be blank.” appears as no trade size has been entered. If the“Send” button 214 is selected in the panel of FIG. 5 , the order of theamount is transferred to the Fix Order Panel 300, as a valid amount of300 has been entered into the Buy Amount box 210. For subsequent orderssubmitted, they are displayed in the existing Fix Orders panel 300,within the appropriate Fix.

These are the rules for the placement of the Fix Order Panel on atrader's screen or display (not shown).

If in a Screen Setup, an Information Panel has been selected to beoverlayed by the Fix Order panel 300, then the Fix Order panel appearswhen the trader submits the Fix order (if a Fix Order panel is notalready displayed). The Fix Order panel overlays the specifiedInformation Panel. The Fix Order panel inherits the height of theoverlayed panel. Alternatively, if in the Screen Setup, no InformationPanel has been selected to be overlayed by the Fix Order panel, then theFix Order panel overlays the Fix Order Request panel 200, 200′ (such asthat of FIG. 5 ). If a Fix Order panel 300 is already displayed, thenthe new Fix order adds to the existing Fix Order panel.

The Fix Order panel 300, once it has been displayed is not overlayed byanother panel. Similarly, the Information panel selected, in the ScreenSetup, to be overlayed by the Fix Order panel, is not overlayed by anypanels other than the Fix Order panel.

As illustrated in FIG. 7 , the body or information window 306 of the FixOrder Panel contains the following: a fix header line 304 displaying theFix Source 308 (the source of the price), words reflecting the type oforder, namely “Fix” 310, Time (the time of the fix) 312, “GMT” (the timezone being used for the fix) 314, followed by double dashed lines 316,for example: WM Fix 16:00 GMT===========

The body of the Fix Order Panel also includes Trader's Fix orders andFix deals. The default sort of the data in the Fix Order Panel is asfollows. Oldest Fix header line 318, followed by Fix orders or tradesincluded in the Fix in ascending order of the submit time (new ordersadded to the bottom) 320. Next oldest Fix header line 322, followed byFix trades included in the Fix in ascending order of the match time 324.Current Fix header line 326, followed by Fix orders or trades includedin the current Fix in ascending order of the submit time 328.

As shown in FIG. 6 , the top or header 330 of the Fix Order Panel 300includes: the name of the panel 332, in this case “Fix Orders” andvarious buttons: a “Release Tickets” button that is conditionallydisplayed (this is discussed below, and not shown in FIG. 6 ), a “ClearAll” button 334, an “Off All” button 336, an “X” button 338 at the topright-hand corner.

The Fix Order Panel 300 also includes a scroll bar 340 on the right sideof the panel, enabling the trader to scroll through rows of Fix ordersand trades that cannot be displayed due to space constraints. When theFix Order Panel 300 is not in focus, as new orders are added, thecontents of the panel automatically scroll to display the new orders.When there are overlapping Fixes, that is to say orders can be submittedto more than deal that can later have the price fixed, a new order maybe entered against any open Fix. The new order is, of course, displayedwithin the appropriate Fix.

The “Release Tickets” button is displayed only if the Fix Deal TicketOption selected by the trading floor administrator (TFA) is atrader-initiated ticket release. When a trader clicks the “ReleaseTickets” button, deal tickets are released to the back office for alltrades to which the Fix Rate has been applied, and trades that have notyet been released. In other words, after a price has been fixed, atrader triggers the release of a deal ticket reflecting the executedorder; it is not released automatically. There is a visual indicationthat the deal tickets have been released. Manually releasing ticketsprovides advantages as regards risk management. By allowing tickets tobe held, management of bank's automatic hedging systems is improved. Byway of example, if the ticket is released automatically and immediately,a bank's automatic hedging systems will also automatically andimmediately hedge against the order being settled. However, if anoffsetting ticket is soon to be released this hedging is unnecessary. Byproviding manual ticket release, unnecessary hedging can be prevented,as ticket release can be delayed.

When a trader clicks the “Off All” button 336, the unmatched portion ofall orders is interrupted. If there are no unmatched orders, no ordersare interrupted.

When a trader clicks the “Clear All” button 334, trade items in the FixOrder Panel are cleared in accordance with the following conditions. Ifthe TFA option is for trader intervention to release deal tickets: clearFixed trades with released deal tickets and associated Fix Time andSource lines. If the TFA option is for automatic release of dealtickets: clear Fixed trades and unfixed trades and associated Fix Timeand Source lines.

When a trader clicks the “X” button 338 at the top right, the Fix OrderPanel 300 closes, only if there are no unmatched orders, no unfixedtrades, and no fixed trades for which deal tickets need to be manuallyreleased. Once the Fix Order Panel has been closed, it is displayedagain, only if a Fix order is submitted. The new display of the FixOrder Panel, based on a new order submit, does not contain dealinformation from prior trading activity.

When the first order is entered for a new Fix, the line with the Fixinformation 304 is displayed, for example: “WM 10:00 GMT===========”.

When the Fix Order panel 300 is not in focus, Fix orders are notinterrupted when the keypad's “Off All” button or key 336 is selected orclicked. When the Fix Order panel is in focus, Fix orders areinterrupted when the keypad's “Off All” key is selected or clicked.

The unmatched portion of all Fix orders is interrupted with acombination of keystrokes that causes a “Super Off All”.

Fix orders cannot be rested.

Prior to Trade Close, a single line 302 for each Fix order submitted bya trader is displayed in the Fix Order panel 300. The line includes:

the submit time 342 of the order;

whether the order is a “Buy” or “Sell” order 344;

the matched amount 346 of the total Fix order amount 348 (i.e., “0 of300” progresses to “100 of 300”, “200 of 300”, as the order is matchedand when the order is fully matched, only the matched amount isdisplayed, i.e., “300”);

while there is no part of the Fix order matched (as shown in FIG. 6 ),the field to the right of the amounts (counterparty) is blank;

when there is a single match of the Fix order, as shown in FIG. 8 thefield to the right of the amounts contains the counterparty deal code350 followed by the matched amount 352 in parenthesis (in this example100);

when there are multiple matches for the Fix order, the firstcounterparty deal code and matched amount is displayed and a visualindicator of multiple matches is displayed (this is shown in FIG. 9 , bythe ellipsis “ . . . ” after the counterparty deal code 350 followed bythe matched amount 352 in parenthesis);

currency pair 356 for which the order is for;

an “X” button 358 to interrupt the unmatched portion of the order (thisbutton is conditionally displayed; it is displayed only if there is anunmatched portion of the order); and

the unmatched amount 360 is shown in a particular different colour, inthis example, it is red.

There may be multiple Fix orders displayed for the same currency pairwithin a Fix. And there may be multiple Fix orders for multiple currencypairs within a Fix.

When the trader clicks the “X” button 358 to the right of the currencypair, the unmatched portion of the order is interrupted. The unmatchedamount in red 360 is decremented by the amount of the interrupt.Previously matched portions of any order are not interrupted. In thisexample, this action is supported only by mouse selection; this actioncannot be selected using a keypad.

As shown in FIG. 10 , when part of the order is interrupted, only thedone amount 346 of the order is displayed, i.e., in this example, 200,not 200 of 300.

At Trade Open, the panel background changes color. At Trade Close, thepanel background changes color. If displayed, the current Fix Source,Time and dashed lines are displayed in black.

When an amount is matched, there is an alert, and in particular a visualindication is given. In this example, there is a flash of the panelbackground (as indicated by the dashes 362 at the corners of the panel300 of FIG. 8 ).

As shown in FIG. 8 , the first time a portion of the Fix order ismatched the counterparty deal code 350 is displayed with the tradeamount in parenthesis 352.

As shown in FIG. 9 , when there are multiple matches for a Fix order,the first counterparty deal code 350, with the trade amount inparenthesis, is displayed. A visual indicator (in this example ellipsis354) is displayed to indicate multiple matches for the Fix order. Asillustrated in FIG. 11A, if there are multiple matches, the trader isable to move the mouse pointer 364 over the counterparty displayed and atool tip 366, or display panel, pops-up with counterparties'information. The tool tip contains each counterparty 368, followed bythe trade amount enclosed in parenthesis 370. Each counterparty set isseparated by a comma 372. The tool tip is closed (it is no longerdisplayed) by moving the mouse pointer away from it.

As illustrated in FIG. 14 , as portions of a Fix order are matched, thematched number 346 is incremented by the amount of the match, forexample, 200 of 300. As portions of a Fix order are matched, theunmatched amount 360 is decremented by the amount of the match.

As illustrated in FIG. 10 , when the Fix order is completely matched,only the matched amount (trade amount) 346 is displayed, i.e., 200. TheFix order will continue to be displayed in the Fix Order Panel 300, buthas no more matches applied to it.

Trade Close warning is a warning given shortly before the Fix is closedto new orders. The trade close warning is typically given two minutesbefore trade close. In other words, an indication is given to a traderwhen a deadline for receiving orders is near. Other times are possible,such as between one and five minutes before trade close. At Trade CloseWarning, an indication, and in particular a visual indication is given.In this example, the background color of the EBS clock on the title barof the trading screen (not shown) changes color and/or flashes in thesame manner as the Fix Orders panel, for all traders with orders in theFix that is closing. Also, in this example, at Trade Close Warning, asillustrated in FIG. 11B, the Fix Orders panel 300 background colorchanges (in this example, from green to yellow) and/or flashes. Also,the panel background color changes. The rest of the panel, for example,the header line with the currency pair selected by the trader and thebid/offer prices in the panel is unchanged.

As illustrated in FIG. 12 , at Trade Close, the single line for eachsubmitted Fix order is replaced by a line 372 for each trade. So, if anorder was matched five times, five trade lines are displayed. The tradeline includes: the time of the match 374; whether the matched order wasa “buy” or “sell” order 376; the amount of the trade 378; the price ofthe trade 380, the trading floor 382; and the currency pair 384.

At Trade Close, an indication, and in particular a visual indication isgiven. In other words, an indication is given to a trader at a deadlinefor receiving orders. In this example, the background color of the EBSclock on the title bar of the trading screen (not shown) changes colorand/or flashes in the same manner as the Fix Orders panel, for alltraders with orders in the Fix that is closing. At Trade Close, the FixOrders panel background color changes (in this example, the colorchanges to red) and/or flashes (as shown in FIG. 11C). At Trade Close,the trading system cancels the unmatched portion of the Fix orders. Ifany Fix orders were cancelled, the title bar and the panel background ofthe Fix Order Panel 300 give an indication, and in particular a visualindication, which in this example is a flash. Trade close typicallyoccurs 90 seconds before the price fix time. Other times are possible,such as between 30 seconds and 5 minutes before the price fix time.Also, at Trade Close, the Fix Order order type 102 is greyed out in theQuote Panel 100 of FIG. 3 , so that it can no longer be selected.

When the trading system receives the Fix Rates from NRM, prices areadded to the Trade lines. If the rate for the Fix has not been receivedby the Fix Rate Alert or warning time, then the trading system sends amessage to a FX support portal (FSP) (not shown) requesting missingrates for the appropriate currency pairs within the Fix.

Credit calculation for Fix orders is no different from that of any othertype of order.

After the Fix rates have been applied to the trades, the rates aredisplayed visually differentiated from the other information on thetrade lines as described above in relation to FIG. 12 .

Selecting, for example by double clicking, a Fix trade causes adrop-down menu to be displayed (not shown) with two menu items: DealTicket Summary and Deal Log. The trader may select either menu item.

An Amend Fix Orders of the Fix Order Panel 300 is provided. This isillustrated in FIG. 13 . Fix orders can be amended to a reduced amountas follows. When a trader sets focus on a Fix order 372 in the Fix Orderpanel 300 of FIG. 12 , either the “SEND” button on a keypad (not shown)or a mouse click, allow the trader to amend the Total Amount of theorder as an Amend Fix Orders display panel 400 as shown in FIG. 13appears. The trader can enter a new (amended) Total Amount by enteringit in a box 402 in the Amend Fix Orders of the Fix Order Panel. Whilethe order is in focus to be amended, the Fix order can continue to bematched. The displayed Matched Amount continues to be updated, ifrequired.

Both the Total Amount and the Matched Amount are visible to the trader,i.e., 100 of 500. The trader re-sends the amended amounts by selecting a“Re-Send” button 404 or the trader can cancel the transaction byselecting a “Cancel” button 406. This includes only Fix orders that havebeen zero filled or partially filled. In other words, selecting a“Cancel” button 406 ceases amendment processing. Selecting a keyboard“Resend” button 404 or keypad “Send” key, initiates editing against thenew amount entered (Edits are the same as for Spot amendment) with thefollowing criteria. A request to amend the Fix Order amount to the sameoriginal amount is ignored;

the Fix Order amount cannot be zero;

the Fix Order amount cannot be increased and if an attempt to do this ismade the error text of “Invalid trade amount” or other similar wordingis displayed;

the Fix Order amount is equal to or greater than the Minimum Trade Sizefor the currency pair;

the increment of the Fix Order amount change must be valid for thecurrency pair;

the Fix Order amount must be equal to or less than the original amount;

if the amended amount is equal to or less than the matched amount, theoriginal order is considered “done”.

When the keyboard “Resend” button or keypad “Send” key, is selected fora valid order, the Fix Order Panel remains in focus and the unmatchedamount and the total Fix order amount are updated. The total Fix orderamount is replaced by the amended amount entered by the trader. Theunmatched amount is recalculated as follows:

Unmatched Amount=Total Fix order amount−matched amount.

In the Main Trading window (not shown), “Sign Off” is not enabled when:a Fix Order Request panel is active; and the Fix Order panel containsorders, Unfixed trades (Fix Rates have not been applied), or Fixedtrades for which deal tickets have not been released.

The trading system includes various administrative screens forconfiguring a user trader's preferences. A Screen Setup display 500 isshown in FIG. 14 .

By selecting appropriate buttons on the display 500, a trader candesignate that the Fix Order panel, will overlay an Information Panelwhich is already selected to be shown. The Resting Order panel can neverbe able to be selected for overlaying. A trader can only select, atmost, one Information panel, at a time, to be overlayed. If a traderchooses to hide (deselects) the Information panel that was designated asthe Fix Overlay, the Fix Overlaying is disabled. A trader may choosenone of the Information panels to overlay. In that case, the Fix Orderpanel overlays the Fix Order Request panel. Auto Clear Settings do notapply to the Fix Order Panel.

Parameters are included at the floor level to allow the trading flooradministrator (TFA) to determine whether a floor chooses a Single DealTicket Option for Fix trades, or Two Deal Ticket Option for Fix Trades.The selected options are effective for all traders on the floor.

For the Single Deal Ticket Option, there are two particular features.The deal ticket can be released to the back office automatically afterthe Fix rate has been applied. Alternatively, the deal ticket ismanually released when the trader initiates it, after the Fix Rate hasbeen applied to the deal. The manual release option is only available tofloors using Deal Feed Client. (The option is not available to floorsusing the Deal Feed Alternative via the TFA.)

For the Two Deal Ticket Option, there are also two particular features.They concern the release of the final deal ticket. The first ticket isautomatically released to the back office at match time. The final dealticket is automatically released after the Fix rate has been applied.Alternatively, the deal ticket is released when the trader initiates it,after the Fix Rate has been applied to the deal. The manual releaseoption is only available to floors using Deal Feed Client. (The optionwill not be available to floors using the Deal Feed Alternative.)

The default is a single deal ticket with automatic release of the dealticket.

Changes made by the TFA are effective with the next sign on for thetrader.

Prime Banks are not allowed to choose the manual release of dealtickets.

At startup of the trading system, the trading system obtains a list offloors. The floors are noted, as either Bank or PTC (non-Bank). If thelist of floors is not available from FSP, the trading system does notcome up.

At start up, the trading system obtains the information from FSP foreach Fix as shown in the table of FIG. 15 . This shows the expectedfixing administrative information from FSP. No data structure is impliedin the table.

The trading system converts the Fix Time to GMT using the Fix SourceLocal Time and the Fix Source Local Time Zone. The trading systemcalculates the following times based on Fix Time in GMT:

Trade Open=Fix Time−Trade Open

Trade Close Warning=Fix Time−Trade Close Warning

Trade Close=Fix Time−Trade Close

The trading system adds a date to the Fix Time received from FSP, toprovide uniqueness among days. The trading system converts the Localtime to GMT and the GMT is used for all displays of the Fix Time. Fixingperiods may overlap.

From NRM, the trading system requests fix rates for Fixes that may haveoccurred while the trading system was not available.

At Trader Logon, the trading system queries for orders and trades to bedisplayed in the Fix Order Panel as follows. All unfixed trades andtheir associated Fix Time and Source lines are displayed in a Fix OrderPanel; Fixed trades that have not been released are displayed; Fixedtrades that have been released are not displayed; and of all matchedorders that have not been fixed, the trades are displayed.

Unmatched orders are cancelled by the trading system if a trader isungracefully disconnected.

Post Trade arrangements for deal feed clients (DFC) only are as follows.

As mentioned above, there are two options of deal ticketing. One optionis a single deal ticket per counterparty for each trade. A second optionis two deal tickets per counterparty for each trade. With the singleticket option, the deal tickets are either released automatically afterthe Fix rates are applied to the deals or the trader initiates the dealticket release. With the two-ticket option, the deal ticket produced atmatch time is automatically sent to the back office. The final dealticket is produced after the Fix Rates has been applied to the deals andis released automatically or the trader initiates the deal ticketrelease. The deal ticket option is configurable by trading floor.

For the single deal ticket option, there is one deal ticket for eachtrade. The deal ticket is automatically released to the back office ifthe automatic release option is selected or the trader releases the dealticket if the dealer-initiated option is selected. The deal ticket isgenerated and released or available for release to the back office afterthe Fix Rate is applied to the trade. The rate on the deal ticket is theFix Rate. The time on the deal ticket is the time of the Fix Rateprovided by NRM. Match time is added to the ticket. The Reference Number(deal id or deal identification) has a suffix added to it to indicatethat the deal is a Fix deal.

The trader releases the deal tickets for all Fixed trades by selectingthe “Release Tickets” button 386 on the Fix Order Panel 300 of FIG. 12 .For the two-deal ticket option, only the second deal ticket is releasedwhen the “Release Tickets” button is selected. The first ticket isautomatically released.

For the two-deal ticket option, there are two deal tickets for eachtrade. The first deal ticket is generated at match time andautomatically released to the back office. The rate on the first dealticket is a Smoothed Rate or other indicative rate for the currency pairat the time of the match. The Smoothed Rate is provided by thearbitrator or ARB on the deal message; the Smoothed Rate is applied tothe deal by the ARB. The Smoothed Rate is reformatted to the appropriatenumber of decimal places, conforming with the existing price format. Ifthe rate provided by the ARB is zero, then the trading system alsodisplays zero on the deal ticket. When the rate provided by the ARB iszero, for a Prime deal, there is no spread on the synthetic ticket. Thetime on the first deal ticket is match time. The Reference Number (dealid or deal identification) has a suffix added to indicate that the dealis a Fix deal. The second Deal Ticket is generated after the Fix Rate isapplied to the trade. The second deal ticket has the same deal ticketnumber as the first deal ticket. The second deal ticket is automaticallyreleased to the back office if the automatic release option is selectedor the trader releases the deal ticket if the dealer-initiated option isselected. The rate on the second deal ticket is the Fixing rate. Thetime on the second deal ticket is the time of the Fix Rate provided byNRM. The Reference Number (deal id or dead identification) has a suffixto indicate that the deal is a Fix deal. The suffix is different to thesuffix on the first deal ticket. The suffix appended to the deal id cansupport combinations of Maker Prime, Taker Prime and Fix. A single dealticket and the first deal ticket of the Two Deal Ticket option containthe identical suffix value.

If automatic printing of the deal ticket is enabled, and the automaticdeal ticket release is selected, the ticket prints after the Fix ratehas been applied. If automatic printing of the deal ticket is enabled,and the manual deal ticket release is selected, the ticket prints afterthe ticket has been released.

Fix trades are to be excluded from Trader Deals, EBS Deals, and (deal)Overview panels. Fix trades are, however, included in the Deal Log.

Settlement dates for Fix trades are calculated in the same manner asSpot trades.

A deal log 600 is shown in FIG. 16 . For the purpose of the Deal Logdisplay, whether the trader (floor) has the two-deal ticket option orthe one deal ticket option is determined by the value of the option atthe time of the query, not the value of the option at the time of thedeal.

For the two-deal ticket option, two rows are displayed. One row for theticket generated at match time and another row for the ticket generatedwhen the Fix Rate is applied to the deal. Time is the match time on thefirst deal ticket (Fix rate has not been applied). Time is the time fromNRM on the second deal ticket (Fix rate has been applied). Order Type is“FX”. Price is the Smoothed Rate (reformatted to proper price format) onthe first deal ticket. If the rate provided by the ARB is zero, then thetrading system also displays zero on the deal ticket. When the rateprovided by the ARB is zero, for a Prime deal, there is no spread on thesynthetic ticket. Price is the Fix Rate on the second deal ticket. TheReference Number is the deal id plus the assigned suffix.

Means are provided to sort or filter on Order Type.

For the two deal tickets option, the first deal ticket is excluded fromthe Maker/Taker counts and EBS Deals 602, displayed at the bottom rightof the Deal Log.

Deal Tickets for Fix trades are included in the reports and contain thesame data as is reported in the Deal Log.

Deal Ticket Summary is available for Fix deals. It is accessed by thetrader clicking on a row in the Deal Log, and the deal ticket associatedwith that row is displayed. Deal Ticket Summary can also be accessed bythe trader double clicking a trade in the Fix Order panel. If the Fixrates have not been received by the trading system, then the deal ticketwill display the reference rate. If the Fix rates have been received bythe trading system, then the deal ticket displays the Fix rate.

The Time and Price data are the same as is displayed in the Deal Log. Ifthe deal ticket contains a reference rate (not the Fix rate) then atextual line “Reference rate displayed” is added to the Deal TicketSummary.

The trading system subscribes to the NRM to receive Fix rates. Thetrading system expects to receive the rates shortly after the Fix Timeof each Fix. The Fixing Rate Information required is detailed in thetable of FIG. 17 (no data structure is implied in the table). The tableshows the expected fixing rate information from NRM.

A Fix is defined by its source and a Fix Local Time and Fix Date. TheFix Local Time for each Fix is converted to a particular time zone, inthis example, GMT (Greenwich Mean Time) by the trading system anddisplayed as GMT. Once the trading system receives the Fix Rates foreach currency pair in the Fix, as illustrated in FIG. 16 , the rate 380is applied to each applicable trade and displayed in the Fix Order panel300 for each visible trade.

The same Fix Rates are provided by NRM to each Broker. Each brokerupdates its deals within its database.

The trading system has a configurable Fix Rate Alert. The Alert containsthe amount of time to wait after a “Fix Time” prior to taking action toobtain Fix rates for any currency pairs within a Fix for which dealshave been done and rates have not been received. When any expected Fixrates have not been received and the waiting time after the “Fix Time”has expired, if the Broker has remained continuously connected to NRMsince the “Fix Time”, the Broker sends a notification to FX supportportal (FSP) indicating the Fix and the specific currency pairs forwhich it needs rates.

If the waiting time has expired and the trading system lost connectivitywith NRM since the “Fix Time’, the Broker requests from NRM, Fix ratesfor Fixes that may have occurred while the trading system wasdisconnected. If the NRM has no rates to provide to the Broker, then theBroker sends a notification to FSP indicating the Fix and the specificcurrency pairs for which it needs rates.

At the end of the trading day, the trading system releases to the backoffice all deal tickets with Fix Rates that had not been previouslyreleased. The end of the trading day is defined as the default end ofday (5:00 pm in New York). This requirement is to account for a tradernot releasing his deal tickets. This, and providing multiple dealtickets (rather than a single deal ticket), provides a complete ordertrail at the time match occurred. So, there is a record of a completetrading history. This protects both traders and banks.

At the end of the trading day, the trading system removes Fix OrderPanels when all deal tickets for the trades have been released and thereare no unmatched orders. If Fix Rates are not received by the CurrencyPair at the end of day, the trading system takes no action regarding thedeal tickets.

The trading system cancels all unmatched Fix orders if a trader isungracefully disconnected.

If Fix Rates are to be manually input, they will be input to FSP and FSPwill communicate them to NRM. NRM will publish them to the tradingsystem.

The Trade Open for a Fix is not dependent upon the receipt of the FixRates for the prior Fix.

Fix orders are available to all traders. There is no requirement to turnon/off Fix orders.

ARB provides a configurable Fix order type flag for Market Data, somarket rates feed (MRF) can determine whether or not to include Fixorder types in existing calculators or a new calculator.

For matched Fix orders, the second trader is considered the Taker.

Ticket numbers for Fix deals are generated by the Maker and TakerBrokers at time of trade confirmation. No new ticket numbers aregenerated when the Fixing occurs. Ticket numbers are exchanged betweenthe Brokers using an instruction message.

DSM/DST message to the ARB and subsequently to Netlink will not wait forexchange of ticket numbers. They contain only the ticket number of theside sending the message. Counterparty ticket number is not included onthe DSM/DST.

Customers who have the one ticket solution will receive an out-of-orderticket number, since the ticket number was generated at trade time, butnot released until after the Fixing. Similarly, customers with thetwo-ticket solution will receive an out-of-order ticket number on thesecond ticket.

A list of floors designating each floor as a Bank or PTC (non-Bank) isprovided.

For the Market Data Daily High Low Trades, the three highest and thethree lowest trades are displayed to traders. Although, the source ofthe data may expand beyond three.

Continuous Matching Orders

Like fixing orders described above, Continuous Matching orders areorders entered into a dark pool. Buying interests and Selling interestsare submitted into an anonymous trading system with an amount, but noprice. The orders are only matched by the Arbitrator with otherContinuous Matching orders, based on time in the market, and wherecredit exists between counterparties (there is bilateral credit). Theprice of the deal is set by the Arbitrator at the time of the match,based on pricing from an outside source. The price of matched orders isfixed or set at the same time or immediately after the orders arematched. There may be a very slight delay while the price is set fromthe outside source as these are only updated periodically, typicallybetween once a second and once a minute.

Continuous Matching orders can be submitted by any Bank trading floor,for any currency pair, as well as metals and NDFs.

Although there is a minimum order amount, a Continuous Matching ordermay be matched by the Arbitrator for an amount less than the minimumamount, depending upon the inventory availability.

In the trading system, Continuous Matching will be assigned atwo-character order type, “CM”. Continuous Matching is available for allfungible instruments, such as currency pairs (such as EUR/USD), metalsand non-deliverable forwards (NDFs).

Continuous Matching does not have a set period of time during which theinstruments can be traded. Continuous Matching trades can be madewhenever the Broker is available. This is in contrast to Fixing Ordersdescribed above in which Fixing Orders are only available at particulartimes throughout the trading day.

Credit calculation for Continuous Matching orders is no different thanfor any other type of order.

As in fixed orders described above, the order type shall be added to thedrop-down menu in the Quote Panel 100 of a computer display of atrader's computer terminal so that it can be selected. This isillustrated in FIG. 18 , which is similar in most respects to the panelof FIG. 3 and like features have been given like reference numerals,although this also includes the option to Continuous Match. In thisexample, Continuous Match 105 is shown on the drop-down menu 105, andcan be selected by clicking on it. Continuous Matching on the dropdownmenu is not displayed if the trader's floor is a PTC trading floor.

When the trader selects “Continuous Matching” the Continuous MatchingOrder Request Panel 1000 is displayed in a trader's computer terminaldisplay and this is shown in FIG. 19 .

For the next subsequent order for the same currency pair as the previousContinuous Matching Order, the format of the Order Request panel revertsto the last non-Continuous Matching order type.

The Continuous Matching Order Request Panel 1000 displays:

the currency pair 1002 to be traded in the upper left corner; the text“Continuous Matching Order” (or similar) 1004 at the top center of thepanel; Drop down icon in upper right corner 1006; Buy Amount 1008 andSell Amount fields 1010, blank filled; a “Send” Button 1012; and a“Quit” Button 1014.

The initial focus is on the Buy Amount 1008 (which is located to theleft of the Sell Amount 1010), and the Sell Amount is greyed out, if theBid button had been selected in the Price Panel. Alternatively, theinitial focus is on the Sell Amount, and the Buy Amount is greyed out,if the Offer button had been selected in the Price Panel.

The drop down 1006 in the right upper corner, when selected, displays alist of order types (it is the drop-down menu 104 of FIG. 18 ). If thetrader selects a new order type (non-Continuous Matching) from thisdrop-down menu, then the Quote Panel for the selected order type isdisplayed. There is no carryover of amounts or prices from theContinuous Matching Order Request Panel to any other panel.

If the Bid button had been selected in the Price Panel, the tabbingsequence for the Continuous Matching Order Request Panel is “BuyAmount”, “Send”, “Quit”. Alternatively, if the Offer button had beenselected in the Price Panel, the tabbing sequence for the ContinuousMatching Order Request Panel is “Sell Amount”, “Send”, “Quit.

Selecting the “Quit” button 1014 closes the Continuous Matching OrderRequest panel and the order in the panel is not processed. The focusthen reverts to the Price Panel for the specific currency pair.

If no Buy Amount or Sell Amount is entered in the Continuous MatchingOrder Request panel 1000 and the “Send” button 1012 is selected, anerror message “Trade size can't be blank” (not shown) is displayed.

If the Buy Amount is populated, and the trader decides to sell insteadof buy, then he must select the Offer button in the Price Panel toenable the Sell Amount field in the Continuous Matching Order RequestPanel. The Buy Amount is then cleared by the trading system. The processis vice versa for a sell action changing to a buy action.

Both Buy and Sell pre-match Continuous Matching orders are not permittedsimultaneously for a currency pair. If a trader has an existing BuyContinuous Matching order and a Continuous Matching Sell Amount isentered for the same currency pair, an error message “ContinuousMatching Buy order exists” is displayed (not shown). Similarly, if thetrader has an existing Sell Continuous Matching order and a ContinuousMatching Buy Amount is entered for the same currency pair, an errormessage “Continuous Matching Sell order exists” is displayed. However,for a currency pair, multiple Buy Continuous Matching orders andmultiple Sell Continuous Matching orders are permitted.

The maximum Continuous Matching Buy and Continuous Matching Sell Amountthat can be entered for an order is set to a predetermined value, forexample 999. If less than the minimum Continuous Matching order amountis entered in the Buy or Sell Amount, the existing error message forthis condition is returned to the Trader. The minimum order amount maybe included in the error text.

Most importantly, however, no price is submitted on the order. Only anamount is entered into the buy amount 1008 or sell amount 1010 orderentry boxes of FIG. 19 .

Once a buy amount or sell amount has been entered by a trader and the“Send” button 1012 of FIG. 19 is selected on the Continuous MatchingOrder Request panel 1000, the order is transferred to a “standard”transaction panel or a Continuous Matching Order Transaction Panel 1100of a trader's computer terminal display illustrated in FIG. 20 .

The transaction panel 1100 has neither a thumb tack nor a resting orderwidget. No price information is displayed. There are no unique rules forthe placement of the transaction panel for the Continuous Matchingorders.

As portions of the order are hit, the banner 1102 (which is typicallycoloured yellow) includes the cumulative amount of the hit and theweighted average dealt price.

In this example, Continuous Matching orders cannot be amended, upward ordownward via the transaction panel. All amendments must be no less thanthe minimum Continuous Matching order amount.

Traders who already have an Order in the order book at a given price toincrease the order size without losing priority for existing ordersegments or decrease order size beginning from the order segment withthe lowest priority (LiFo) apply to Continuous Matching orders.

After the trader changes the amount and selects the “Resend” button orkeypad “Send” key (not shown), the entered amount is validated. Foredits, the Continuous Matching Order amount must be equal to or greaterthan the Continuous Matching Minimum Order size for the currency pair.The unmatched portion of all Continuous Matching orders is interruptedwith “Off all” and “Super Off All” keystroke combinations.

Continuous Matching orders cannot be rested or thumb tacked.

If credit is not enabled, a deal is legally binding when recorded in theTaker database. If credit is enabled, a deal is legally binding whenrecorded in either Taker or Maker database.

At start up, the trading system obtains the minimum Continuous Matchingorder size for each currency pair from FSP. If an order size is notavailable for any active currency pair, the trading system does not comeup. At start up, the trading system obtains a list of floors. The floorsare noted as either Bank or PTC (non-Bank).

If the list of floors is not available from FSP, the trading system doesnot come up.

Continuous Matching deals appear in the Trader Deals, Deal Overviewpanels, Deal Log, and DTS, but do not appear in EBS Deals panel. TraderDeals and Deal Log display “CM” as the order type designation forContinuous Matching orders.

Post trade, as with any spot deal, a single deal ticket is generated andautomatically released to the back office at match time. The price to beapplied to the deal and thus the deal ticket is provided by the ARB(arbitrator) and communicated to the Broker. If the rate provided by theARB is zero, then the trading system displays zero on the deal ticket.The zero rate is included in Deal Status messages.

Deal Tickets for Continuous Matching trades are included in reports andcontain the same data as is reported in the Deal Log.

A minimum configurable Continuous Matching order size is establishedglobally for each currency pair. The configurable values are set in FSPand provided to the trading system. The list of Bank floors with theircharacteristics, such as Bank or non-Bank is established and maintainedby in FSP and provided to the trading system.

No specific “minimum quote life” (MQL) (actually minimum order life, asthe orders in the system do not have a price) requirements forContinuous Matching Orders are applied at the Broker.

Credit Manager

As discussed, Credit management and credit decision making is availableat the Credit application rather than the Broker. The credit applicationis located at the arbitrators. However, TFA maintenance of credit mayremain in the Broker and be communicated to the Credit Manager. Creditreporting may remain in the Broker. Credit decisions are made by theCredit application for all trading except trading between Prime Broker(PB) and Prime Customer (PC). Credit between PB and PC will continue tobe determined by the Broker.

The architecture of the anonymous computerised trading system isillustrated in FIG. 21A. It is similar in many respects to that of theprior art system of EP A 625275 described above. In summary, it includesa plurality of arbitrator computers configured to match orders betweencounterparties in the system. Each order comprises an amount of afungible instrument to buy or sell, but no price. A credit managercomputer is associated with each arbitrator computer. Each creditmanager computer is configured to determine whether a predeterminedlevel of credit is available between counterparties (bilateral credit)before orders between counterparties are matched. The orders are matchedbased on a price from an outside price stream. They are not matched atprices on the trading system.

As mentioned above, the trading system includes a credit managerassociated with each arbitrator. So, there are a plurality of creditmanagers. The components illustrated in FIG. 21A, namely thearbitrators, the market access node and trader workstations are each acomputer or computers arranged on network. These components areconnected together on a computer network. The credit manager may beimplemented on the same computer as the arbitrator or the credit managermay be implemented on a separate computer or computers on a network tothe arbitrator.

Each credit manager may be located at the same site as each arbitratoror located nearby, such as in the same city (New York, Tokyo, or London)or in the vicinity of the arbitrator. The credit manager stores andmaintains a pre-authorization credit matrix, like that of EP A 625275,which is illustrated in FIG. 21B.

The rows and columns of the matrix of FIG. 21B are associated with thevarious Trading Floors A1 a, A1 b, A2 a, etc. The credit manager storesthe credit matrix. Preferably, each credit manager associated with eacharbitrator only maintains a partial Preauthorization Matrix containingdata only regarding credit extended between trading floors in itslocality and other trading floors in its and other localities. Thus, asindicated in FIG. 21B by cross hatching, some of the matrix entries maybe blank. For each ordered pair of Trading Floors {TFi, TFj}, the creditmatrix contains an indication as to whether TFi has extended any creditto TFj. In the depicted example, credit exists on a bilateral basisbetween TFA1 and TFA2, no credit exists between TFA1 and TFB1, andcredit has been extended unilaterally from TFB1 to TFA2, but not viceversa (as indicated by the “1” at the intersection of row TFB1 withcolumn TFA2 and the “0” at the corresponding intersection of column TFB1with row TFA2). From the main diagonal of the matrix it can be seen thatonly TFA2 permits its own traders to trade between themselves, asindicated by the “1” at the intersection of row TFA2 with column TFA2.

While credit availability between trading floors has been described, thesystem using a credit manager allows credit to be assigned based onfactors other than trading floor or deal code, such as the financialinstrument or fungible instrument being traded between the parties (forexample, particular currency pairs for FX trading, non-deliverableforwards (NDFs), or metals). This approach also allows the credit matrixto reflect credit available between institutions (rather than justparticular trading floors of institutions).

Orders are matched by arbitrators using a price set from an outsideprice stream. Preferably, the arbitrator in the region of the tradersbeing matched is used.

No market view is provided to traders to show them particular pricesavailable to them in the market based on credit they have withprospective counterparties. This is because they do not see pricesavailable to them. Orders entered into the system, do not include aprice, but only an amount. Orders are entered into a dark pool.

The arbitrators are in communication connection with market access nodesor brokers. The market access nodes are each under the control of atrading floor administrator (TFA). They maintain confidential recordsincluding transaction records and credit limits between prospectivecounterparties.

Trader workstations or computer terminals where orders are input intothe trading system by traders are in communication connection with themarket access node associated with the trading floor of the trader.

In the example given, the implementation of this credit approach is doneat the floor level. For a period of time, trading can transact between afloor using this credit approach and a floor using the known creditapproach (of EP A 625275). For the most part, while there is a mixedmode of credit between the two trading floors, the existing dealprocessing takes precedence. Known deal processing continues with theaddition of the Broker of the credit enabled floor, also communicatingwith the Credit Manager for both deal confirmation and creditmanagement.

If any credit management or credit decision making are carried out bythe Broker, credit information stored by the Broker and the CreditManager are synchronised with each other.

When a PB (prime broker) floor is enabled for credit, all of its PCs(prime customers) are also enabled for credit. Conversely, a PC floor isnot enabled if the PB floor is not enabled.

The Broker indicates to the ARB at sign on time, if the floor is usingthe known credit approach or the Credit approach described herein, wherethe credit matrix is stored at a credit manager.

When the Broker starts up or detects that MQ comes up, the Brokerprovides to the Credit Manager summary credit information for each ofits floors for which Credit has been activated. If the summaryinformation does not match Credit Manager's view, then Credit Managerrequests the Broker to provide detailed credit information for themismatched floors. In response, the Broker provides the requesteddetailed information.

Credit Manager may also initiate synchronization with the Broker whenCredit Manager comes up and the Broker is already up.

The Credit Manager requests whether or not the floor allows intrafloordealing.

The trading system responds to the Credit Manager's request with theintrafloor indication.

When the Credit Manager determines all summary information and anyrequested floor information is synchronised with its data, the CreditManager sends a request to the Broker for the Credit Used amount foreach credit group for the synchronized floor. The Broker provide to theCredit Manager the Credit Used amount for each credit group in therequested floor.

The Broker ensures that the Credit Used amount includes credit only fordeals for which Deal Confirmations have already been sent to the CreditManager.

An Ai (an automated trading tool) establishes each trading session foreach trader of a given floor that has been configured in Ai with the“Floating Option”, Ai provides to the trading system the Deal CodeThroughput Allocation and the Trader Throughput Allocation. Deal CodeThroughput Allocation (DCTA) is the number of orders permitted for theDeal Code within a time interval. Trader Throughput Allocation (TTA) isthe number of orders permitted for the specific trader within a timeinterval.

The trading system stores the Deal Code Throughput Allocation and theTrader Throughput Allocation provided by Ai. If the Deal Code ThroughputAllocation value changes with subsequent trading session establishments,the trading system replaces the stored value.

For the initial session establishment for the first trader of a givenfloor, the Deal Code Current Usage is set to the Trader ThroughputAllocation. For subsequent session establishments for additional tradersof a given floor, the trading system calculates the Deal Code CurrentUsage by adding the Trader Throughput Allocation to the existing DealCode Current Usage (DCCU). For session terminations, the trading systemcalculates the Deal Code Current Usage by subtracting the TraderThroughput Allocation from the existing Deal Code Current Usage (DCCU).When the attempted establishment of a trading session would result inthe Deal Code Current Usage exceeding the Deal Code ThroughputAllocation, the trading system does not update the Deal Code CurrentUsage. When the attempted establishment of a trading session wouldresult in the Deal Code Current Usage exceeding the Deal Code ThroughputAllocation, the trading session is not allowed and an error message isreturned to Ai. The error message includes: Trader ThroughputAllocation; Deal Code Throughput Allocation; Deal Code Current Usage;and Deal Code Available Amount (DCTA-DCCU).

FIG. 22 is an example of Ai establishing a trading session for Aitraders on a given floor.

FIG. 23 illustrates a dealing flow among the Broker, ARB, and CreditManager (CM) embodying an aspect of the present invention.

After the orders have been matched by the ARB (arbitrator), a dealnotification from the ARB containing all existing deal information,trade date, and both Taker and Maker credit information is sent to bothBrokers. Neither Broker recalculates credit and both Brokers use thecredit information and trade date provided by the ARB. (The Brokersshall continue to calculate credit between the PB and PC at ordersubmission for prime deals.) If the trade date provided by the ARB, isnot the current trading day, then the credit amount is not added to theGroup's credit used amount.

Each Broker records the deal when it receives the deal notification fromthe ARB. A deal is legally binding when either Broker records the deal.

In this arrangement, the Brokers do not exchange a deal verification andthey do not assign a trade date. The trade date is provided on the dealnotification from the ARB.

Both Brokers continue to exchange counterparty specific deal informationwith the counterparty Broker and continue to send deal status to theARB. The deal status, in addition to deal information, contains its owncredit information for the trading floor.

Each Broker sends a deal confirmation to the Credit Manager. In additionto deal information, it contains its own credit information. The dealconfirmation also contains the total amount of credit used for thecredit group.

The deal pending message is not displayed on the Transaction Panel. Thisis because there is no longer a pending state while credit is checked.

The BP-API simulates the current Deal Pending message for downstreamapplications.

For a Mixed Credit Approach, when only one trading floor is enabled forthe credit approach described above using a credit manager, all currentdealing processes remain in place. The deal confirmation message fromthe Broker to the Credit Manager is sent only from the Broker with thecredit enabled floor.

FIG. 24 illustrates a dealing message flow among the Broker, ARB, andCredit Manager when only the Taker Broker's floor is enabled for credit.This is an example where only the taker is enabled for credit and it's asuccessful deal flow. That is to say, when the Taker Broker's floor isenabled and the Maker Broker's floor is not enabled for the creditapproach described herein.

After the orders have been matched by the ARB, a hit notification fromthe ARB containing the Taker's credit information shall be sent to theMaker Broker. The trade date is not included on the hit notification.The Maker Broker confirms credit and sends a deal verification with theTaker's credit information to the Taker Broker. The Maker may havereduced the amount of the deal. The Taker Broker accepts the creditinformation, generates a trade date and sends a verificationacknowledgement of the deal to the Maker Broker. If the Maker Broker hadreduced the deal amount, then the Maker Broker proportionately reducesthe Taker's credit. A deal is legally binding when the Taker Brokerrecords the deal after receipt of a DealVerify message. Both Brokerscontinue to exchange counterparty specific deal information with thecounterparty Broker and continue to send deal status to the ARB. Thedeal status, in addition to deal information, contains its own creditinformation for the trading floor. If the deal amount has been reduced,the deal status reflects the reduced credit amount. Only the TakerBroker sends a deal confirmation to the Credit Manager. In addition todeal information, it contains its own credit information for the tradingfloor. If the deal amount has been reduced, the deal confirmationreflects the reduced credit amount. The deal confirmation also containsthe total amount of credit used for the credit group.

FIG. 25 illustrates a modified successful dealing flow among the Broker,ARB and Credit Manager when only the Maker Broker's floor is enabled forcredit. That is to say, when the Maker Broker's floor is enabled and theTaker Broker's floor is not enabled for the credit approach describedherein.

After the orders have been matched by the ARB, a hit notification fromthe ARB containing the Maker's credit information is sent to the MakerBroker. The Maker Broker accept the credit information and sends a dealverification with the Maker's credit to the Taker Broker. The TakerBroker confirms credit, generates a trade date, and sends a verificationacknowledgement of the deal to the Maker Broker. The deal amount may bereduced by the Taker Broker. If the Taker Broker has reduced the dealamount, then the Taker Broker proportionately reduces the Maker'scredit. A deal is legally binding when the Taker Broker records the dealafter receipt of the DealVerify message. Both Brokers continue toexchange counterparty specific deal information with the counterpartyBroker and continue to send deal status to the ARB. The deal status, inaddition to deal information, contains its own credit information forthe trading floor. If the deal amount has been reduced, the deal statusreflects the reduced credit amount. Only the Maker Broker sends a dealconfirmation to the Credit Manager. In addition to deal information, itcontains its own credit information for the trading floor. If the dealamount has been reduced, the deal confirmation reflects the reducedcredit amount. The deal confirmation also contains the total amount ofcredit used for the credit group.

FIG. 26 illustrates an unsuccessful dealing flow when the Maker Broker'sfloor is enabled for credit and the Taker Broker fails for credit. Thatis to say, when the Maker Broker's floor is enabled and the TakerBroker's floor is not enabled for the credit approach described hereinand the Taker Broker fails the credit check.

After orders have been matched by the ARB, a hit notification from theARB containing the Maker's credit information is sent to the MakerBroker. The trade date is included on the hit notification. The MakerBroker accepts the credit information and sends a deal verification withthe Maker's credit to the Taker Broker. When the Taker Broker checkscredit and determines there is no credit, the Taker Broker sends averification acknowledgement to the Maker Broker with the Maker's creditand indication of denial of the deal. Both Brokers continue to send dealstatus to the ARB. The deal status contains its own credit informationfor the trading floor if applicable, and indicates that there is nodeal. Neither Taker Broker sends a deal confirmation to the CreditManager.

FIG. 27 illustrates an unsuccessful dealing flow when the Maker Broker'sfloor is enabled for credit and the Maker Broker fails for credit. Whenthe Credit Engine at the Maker ARB fails the credit check the hit quoteacknowledgement sent to the Taker ARB will indicate that there is nocredit. If there are no other successful matches for the order, theTaker Broker is notified that hit was done for zero.

FIG. 28 illustrates an unsuccessful dealing flow when the Taker Broker'sfloor is enabled for credit and the Maker Broker fails for credit. Thatis to say, when the Maker Broker's floor is disabled and the TakerBroker's floor is enabled for the credit approach described herein andthe Maker Broker fails the credit check.

After the orders have been matched by the ARB, a hit notification fromthe ARB containing the Taker's credit information is sent to the MakerBroker. The trade date is not included on the hit notification. When theMaker Broker checks credit and determines that there is no credit, theMaker Broker sends a Deal Failure message with the Taker's creditinformation, to the Maker ARB. Both Brokers continue to send deal statusmessages to the ARB. The deal status contains its own credit informationfor the trading floor, if applicable, and indicates that there is nodeal.

In one arrangement, a Deal Status message is sent by the Broker to theARB when the Maker Broker fails credit. In another arrangement, a DealStatus message is not sent by the Broker to the ARB when the MakerBroker fails credit.

FIG. 29 illustrates an unsuccessful dealing flow when the Taker Broker'sfloor is enabled for credit and the Taker Broker fails for credit.

When the Credit Engine at the Taker ARB fails the credit check, there isno exchange of messages between the ARBs. If there are no othersuccessful matches for the order, the Taker Broker is notified that thehit was done for zero.

We now turn to Amends and Interrupts of orders. The Broker does notassume that Order Amend requests or Order Interrupts are granted by theARB, but must wait for the notification from the ARB before completingthe Amend or Interrupt request. This requirement is applicable wheneither or both floors are enabled for the credit approach describedherein. The trader will be unable to further amend or interrupt theorder until the acknowledgement is received from the ARB

For basket orders, the Broker needs to receive from the ARB, the priceof one of the components of the deal. For Basket/Ruble, for example, thetrading system needs the EUR/USD rate in the DealNotify message. The ARBprovides the last dealt rate for EUR/USD. The ARB persists with Friday'slast dealt rate for use on Monday morning, if necessary.

When both floors are enabled for Credit, deal ticket numbers andinstructions, previously generated by the Taker Broker after the dealwas verified and by the Maker Broker after the deal verificationacknowledgement, are generated upon receipt of the deal notificationfrom the ARB.

As regards deal tickets, when both floors are enabled for the creditapproach described herein, for Deal Feed Alternative (DFA), the DST/DSMfrom which the tickets are generated by DFA, continues to contain onlythe ticket number from the side generating the status message.

When both floors are enabled for the credit approach described herein,for Deal Feed Client (DFC), the counterparty ticket number is exchangedin the instruction messages instead of the deal verification and dealverification acknowledgement messages.

For floors enabled for the credit approach described herein, the Brokerno longer sends credit matrix information to the ARB. The ARB's creditmatrix information comes from the Credit Engine.

Currently, the credit matrix indicates whether or not intrafloor dealingis on. When the credit matrix is not provided by the Broker, the Brokerprovides another mechanism to inform the ARB of intrafloor dealing.

TFA Updates: for floors enabled for the credit approach describedherein, all Credit administrative related updates on the Broker are sentto the Credit Manager. The Credit administrative related updates areadditions, modifications and deletions to: Unique Credit GroupIdentifier (unique within floor), Credit Groups, Default Daily CreditLimit, Adjustment Amount, counterparty floors, allow/disallow tradingfor counterparty floors, conversion rates for currencies, ContinuousLinked Settlement (CLS), CLS currencies, CLS percentage, CLS enabledfloors, NDF volatility, NDF scaling factor, NDF scaling method, andCredit Limit Currency (CLC).

The Broker waits for an acknowledgement from the Credit Manager forcredit administrative related updates, prior to updating its databaseand providing the workstation a response message. When the Brokerreceives a positive acknowledgement, the Broker updates its database andprovides a success message to the workstation informing the user thatthe request was processed. When the Broker receives a negativeacknowledgement with an error code indicating that synchronizationbetween the Credit Manager (CM) and the trading system is not required,the Broker updates its database, and provides a message to theworkstation informing the user that the request is delayed. The text ofthe message is: “Your change has been submitted and will be appliedshortly. If there are any issues, Customer Support will contact you”.When the Broker receives a negative acknowledgement with an error codeindicating that synchronization between CM and the trading system isrequired, the Broker: updates its database, provides a message to theworkstation informing the user that the request is delayed (the messagetext given above is provided), and initiates the synchronization processwith CM. When the Broker does not receive any acknowledgement within aconfigurable amount of time, the Broker: updates its database, providesa message to the workstation informing the user that the request isdelayed (the message text given above is provided). Resynchronizationwill be initiated by either CM or Broker, depending upon the situation.The Broker prohibits a Prime Bank from including both a Spotcounterparty and a Prime Customer in the same credit group. Thisconstraint is due to the Broker making credit decisions for tradingbetween PB and PC and Credit Engine making credit decisions for Spot toPB trading.

The Broker rolls over credit at the end of the trading day (5:00 pm NewYork time, Monday to Thursday and Saturday) as is done today. Inaddition, a message is sent to the Credit Manager indicating that theBroker's credit has been cleared for each Credit Group. A knownarrangement is used for end-of-day credit reporting.

Deal recovery when both floors are enabled for the credit approachdescribed herein is now discussed.

First missing instructions, as illustrated in FIG. 30 , are discussed.When Broker2 receives deal notification from the ARB, but does notreceive instructions from Broker1, after a configurable period of time,it sends a “deal in progress” message to all FSPs and a durable recoverymessage to Broker1, providing all of Broker2's order, credit and dealinformation, and requesting Broker1's instructions. Broker1 provides adurable recovery message with its order, credit, deal, and instructionsto Broker2. If either Broker crashes before it has sent the message toFSP or the counterparty Broker, upon start up, the Broker continues therecovery process.

A missing deal notification from ARB is now discussed with reference toFIG. 31 . When Broker2 receives instructions from Broker1, but does notreceive deal notification from the ARB, after a configurable period oftime, it sends a “deal in progress” message to all FSPs and a durablerecovery message to Broker1, providing order, credit and instructioninformation, and requesting Broker1's deal information. Broker1 providesa durable recovery message with its order, credit, deal, andinstructions for the order to Broker2. Broker2 sends the deal status tothe ARB, and the deal confirmation to the Credit Manager. Broker1 doesnot send an instructions message to Broker2. If either Broker crashesbefore it has sent the message to FSP or the counterparty Broker, uponstart up, the Broker continues the recovery process. Broker2 saves thedeal id for a period of time, to ensure that it will not create a newdeal if it receives the deal notification from the ARB.

A missing deal notification and instructions is now discussed withreference to FIG. 32 . When Broker2 receives neither instructions fromBroker1, nor deal notification from the ARB, it later receives arecovery message from Broker1 providing its order, credit, dealinformation, and instructions, and requesting Broker2's instructions.With receipt of the deal information, Broker2 sends the deal status tothe ARB, and the deal confirmation to the Credit Manager. Broker2 sendsa deal in progress to all FSPs and a durable recovery message to Broker1providing order, credit, deal information, and instructions. Broker2saves the deal id for a period of time, to ensure that it will notcreate a new deal if it receives the deal notification from the ARB.

A missing deal confirmation is now discussed with reference to FIG. 33 .When the Credit Manager does not receive the deal confirmation fromBroker2, there is no recovery from the Broker's perspective. (CM wouldhave been notified of the finalized deal by the ARB).

A missing deal status is now discussed with reference to FIG. 34 . Whenthe ARB does not receive the deal status from Broker2, there is norecovery from the Broker's perspective. (ARB will send E1 to FSP)

A broker being unavailable is now discussed with reference to FIG. 35 .When Broker2 is not available, dealing messages are not received orsent. Deal recovery is initiated by Broker1 due to non-receipt ofinstructions. Broker1 sends a deal in progress message to all FSPs and adurable recovery message to the unavailable Broker2, providing itsorder, credit, deal information, and instructions, and requestingBroker2's instructions. The unavailable Broker2 picks-up Broker1'smessage when it becomes available. When available, Broker2 sends thedeal status to the ARB, and the deal confirmation to the Credit Manager.The Broker sends a “deal in progress” message to all FSPs and a durablerecovery message to Broker1 providing its order, credit, dealinformation, and instructions.

Deal recovery when only one floor is enabled for the credit approachdescribed herein follows the known “Deal in Doubt” process. If the dealrecovery fails, the deal status message sent to the ARB includes creditinformation.

CQI is implemented for all Brokers and the GQI option on the OPS webpage is disabled. The credit application described herein is notmanaging credit between PB s and PCs. If a Broker crashes during a dealin progress process, after the Broker has sent its recovery messages, MQwill ensure that the messages are delivered.

Ai (an automated trading interface) integration into the system is nowdescribed.

For an Ai multi session, multiple traders of a Deal Code are supportedon a single Ai Instance. Multiple deal codes can be supported on asingle Ai instance.

Ai subscribes for market views at a floor level. There may be multiplefloors within an Ai server and each floor may contain multiple users.

In support of Ai multi session, the trading system adds floor to theauthentication of an Ai Client, so it includes: Ai server's IP address,User Id, Password, and Floor.

The trading system allows the same Ai server IP address to belong tomore than one trading system domain, thus allowing multiple floors froma single Ai server to log on to a single Broker or multiple Brokers.When adding an IP address to a Broker, if the IP address is in multipledomains, the “super user” is notified of the multiplicity in a pop-upwindow. Ai identifies itself to the BP-API as a multi session serverwith GA-like property settings.

An Ai instance that caters to multiple floors needs an MF-RTV. Thetrading system provides to Ai a mechanism for Ai to request Market Viewsat a floor level through a proxy user session for each floor. Only theproxy user subscribes for and receives Market Views. Ai does not managethe aggregation of the Market View subscriptions of the Ai traders of afloor. Ai manages the distribution of the appropriate market views toeach trader of the floor. Different traders may subscribe to marketviews for different currency pairs. The local RTV configuration isupdated with the Ai floors to which the RTV provides market views foreach Broker. The trading system provides Ai with the ability toconnect/authenticate with a Broker that caters to the Ai User's floor.An Ai floor enabled for MF-RTV is identifiable on the Broker OpsWebpage.

The three highest trades and the three lowest trades of the day bycurrency pair are available in a Market Data Panel. The trading day isdefined the same as for all other market data, which is:

-   -   trading begins Monday 5:00 am Sydney time    -   trading ends daily 5:00 pm New York time    -   trading ends for the week Friday 5:00 pm New York time.

The trading system subscribes to NRM for the (global) Current day DailyHigh/Low Deals. The Market Data Panel drop down menu has an entry for“Daily High Low Deals”. Selection of “Daily High Low Deals” displays aDaily High Low Deals panel with sixteen available positions for thedisplay of currency pairs. The panel allows the trader to select up tosixteen currency pairs to be displayed. The trader selects a specificcurrency pair and the three daily high and the three daily low deals aredisplayed for the selected currency pair.

For each dealt rate, the display reflects:

the three lowest dealt rates with the highest rate on the top of thelist and the lowest rate on the bottom of the list;

the three highest dealt rates for the trading day with the highest rateon the top of the list and the lowest rate on the bottom of the list;

the dealt time, formatted HH:MM:SS; and

the designation of Paid or Given.

Until sufficient trades have occurred, the rates displayed may reflectless than three dealt rates. In that case the second and/or thirdentries are empty. If multiple deals are at the same High/Low, thedisplay reflects multiple deals with the same rates with different dealttimes. When there are multiple deals at the same rate, the deals shallbe presented in descending order with the most current time at the top.

The implementation of settlement dates for the Gulf Coast Currency pairsis by obtaining the settlement dates from FSP. The settlement datesshall be effective in the trading system for the next business day.

The invention has been described with reference to exampleimplementations, purely for the sake of illustration. The invention isnot to be limited by these, as many modifications and variations wouldoccur to the skilled person. The invention is to be understood from theclaims that follow.

1. A computer implemented method comprising: receiving, by an arbitratorcomputer of a plurality of arbitrator computers, from a computer tradingterminal of a plurality of computer trading terminals associatedtherewith, an electronic trade order counter to another electronic tradeorder received from another of the plurality of computer tradingterminals by the arbitrator computer associated therewith; forwarding,by the arbitrator computer, the received electronic trade orders to acredit manager of a plurality of credit manager computers associatedtherewith, wherein each of the plurality of credit manager computersstores a credit matrix of a plurality of credit matrices storing dataindicative of credit extended between a plurality of trading entities,wherein the arbitrator computer is located in a same location as theassociated credit manager computer so as to provide low network latencybetween a time the electronic trade order is transmitted from theassociated computer trading terminal and received by the arbitratorcomputer and a time that a match is made by the arbitrator computer;matching, by the arbitrator computer, the received electronic tradeorders only when the associated credit manager computer has accessed thestored credit matrix and determined that the trading entities associatedtherewith have a predetermined level of credit.
 2. The computerimplemented method of claim 1, wherein the arbitrator computer islocated geographically more proximate to the associated computer tradingterminal of the plurality of computer trading terminals than others ofthe plurality of arbitrator computers.
 3. The computer implementedmethod of claim 1, wherein each credit matrix of the plurality of creditmatrices stored by the plurality of credit manager computers comprises adifferent one of a plurality of partial pre-authorization creditmatrices, each of the plurality of partial pre-authorization creditmatrices storing data indicative of only credit extended between asubset of a plurality of trading entities associated with a particularcredit manager computer and a remainder of the plurality of tradingentities associated with others of the plurality of credit managercomputers; and wherein the associated credit manager of the plurality ofcredit manager computers does not have access to any of the partialpre-authorization credit matrices stored in the others of the pluralityof credit managers.
 4. The computer implemented method of claim 1,wherein the arbitrator computer is located in one or more of a samebuilding, city or country as the associated credit manager computer. 5.The computer implemented method of claim 1, wherein the arbitratorcomputer is located in a same geographic region as the associatedcomputer trading terminal.
 6. The computer implemented method of claim1, wherein the electronic trade orders are received during a tradingperiod and matched during the trading period, when the associated creditmanager computer has determined that the trading entities associatedtherewith have a predetermined level of credit, based on quantity butnot price, the method further comprising: forwarding, during the tradingperiod, by the arbitrator computer, in response to the match ofparticular counter electronic trade orders, a respective first dealticket to at least one of the trading entities associated with thereceived electronic trade orders, the first deal ticket identifying thematched particular counter electronic trade orders and including anestimated price using an indicative rate of a fungible instrument of thematched particular counter electronic trade orders; and applying, by thearbitrator computer after an end time of the trading period, a fixingprice, which is different than the estimated price, to the particularcounter electronic trade orders that were matched during the tradingperiod based upon pricing information received from an outside sourceand forwarding a respective second deal ticket to at least one of thetrading entities associated with the particular counter electronic tradeorders, the second deal ticket identifying the matched particularcounter electronic trade orders and including the fixing price.
 7. Thecomputer implemented method of claim 6, wherein a trading entityreceives a notice that one of the trading periods is about to expire ora time for receiving electronic trade orders is about to expire.
 8. Thecomputer implemented method of claim 6, wherein after the arbitratorcomputer applies a price to the particular counter electronic tradeorders that were matched during the trading period, a trading entitytriggers release of a deal ticket reflecting the priced, matchedparticular pair of counter trade orders.
 9. The computer implementedmethod of claim 6, further comprising issuing a deal ticket for thematched particular counter electronic trade orders which have beenpriced.
 10. The computer implemented method of claim 6, furthercomprising informing a trading entity when one of the receivedelectronic trade orders is matched or partially matched.
 11. Thecomputer implemented method of claim 6, further comprising a tradingentity amending the quantity of one of the received electronic tradeorders associated with the trading entity.
 12. The computer implementedmethod of claim 6, wherein the received electronic trade orders arefirst received electronic trade orders, the trading period is a firsttrading period and the pricing information is a first pricinginformation, and after an end time of the first trading period, themethod further comprising: receiving, by the arbitrator computer, asecond plurality of electronic trade orders, each second electronictrade order being associated with a second trading period having a starttime and an end time, each of the plurality of second electronic tradeorders specifying a quantity to buy or sell but not a price therefore;matching, by the arbitrator computer, two or more of the secondplurality electronic trade orders counter to each other based onquantity but not price during the second trading period; cancelling,automatically by the arbitrator computer without user intervention, allof the second plurality of electronic trade orders associated with thesecond trading period that were not matched during the second tradingperiod; and applying, by the arbitrator computer after the end time ofthe second trading period, a price to the second electronic trade ordersthat were matched during the second trading period based upon secondpricing information received from the outside source.
 13. The computerimplemented method of claim 12, wherein the first and second tradingperiods take place in a single trading day.
 14. An electronic tradingsystem comprising: an arbitrator computer of a plurality of arbitratorcomputers configured to: receive, from a computer trading terminal of aplurality of computer trading terminals associated therewith, anelectronic trade order counter to another electronic trade order counterthereto, the other electronic trade order received by the arbitratorcomputer from another of the plurality of computer trading terminalsassociated therewith; forward the electronic order to a credit managercomputer of a plurality of credit manager computers associatedtherewith, each of the plurality of credit manager computers storing acredit matrix of a plurality of credit matrices storing data indicativeof credit extended between a plurality of trading entities, wherein theassociated credit manager is located in a same location as thearbitrator computer so as to provide low network latency between a timethe electronic trade order is transmitted from the associated computertrading terminal and received by the arbitrator computer and a time thata match is made by the arbitrator computer, wherein the associatedcredit manager is configured to access the stored credit matrix todetermine whether, for the received electronic trade orders, tradingentities associated therewith have a predetermined level of credit; andmatch the received electronic trade orders only when the associatedcredit manager computer has determined that the trading entitiesassociated therewith have a predetermined level of credit.
 15. Thesystem of claim 14, wherein the arbitrator computer is locatedgeographically more proximate to the associated computer tradingterminal than others of the plurality of computer trading terminals. 16.The system of claim 14, wherein each credit matrix of the plurality ofcredit matrices stored by the plurality of credit manager computerscomprises a different one of a plurality of partial pre-authorizationcredit matrices, each of the plurality of partial pre-authorizationcredit matrices storing data indicative of only credit extended betweena subset of a plurality of trading entities associated with a particularcredit manager computer and a remainder of the plurality of tradingentities associated with others of the plurality of credit managercomputers; and wherein the one of the plurality of credit managercomputers is further configured to not access any of the partialpre-authorization credit matrices stored in the others of the pluralityof credit managers.
 17. The system of claim 14, wherein the arbitratorcomputer is located in one or more of a same building, city or countryas the associated credit manager computer.
 18. The system of claim 14,wherein the arbitrator computer is located in a same geographic regionas the associated computer trading terminal.
 19. The system of claim 14,wherein the electronic trade orders are received during a trading periodand matched during the trading period, when the associated creditmanager computer has determined that the trading entities associatedtherewith have a predetermined level of credit, based on quantity butnot price, the system further comprising: the arbitrator computer beingfurther configured to forward, during the trading period, in response tothe match of particular counter electronic trade orders, a respectivefirst deal ticket to at least one of the trading entities associatedwith the received electronic trade orders, the first deal ticketidentifying the matched particular counter electronic trade orders andincluding an estimated price using an indicative rate of a fungibleinstrument of the matched particular counter electronic trade orders,and apply, after an end time of the trading period, a fixing price,which is different than the estimated price, to the particular counterelectronic trade orders that were matched during the trading periodbased upon pricing information received from an outside source andforwarding a respective second deal ticket to at least one of thetrading entities associated with the particular counter electronic tradeorders, the second deal ticket identifying the matched particularcounter electronic trade orders and including the fixing price.
 20. Thesystem of claim 19, wherein a trading entity receives a notice that oneof the trading periods is about to expire or a time for receivingelectronic trade orders is about to expire.
 21. The system of claim 19,wherein after the arbitrator computer applies a price to the particularcounter electronic trade orders that were matched during the tradingperiod, a trading entity triggers release of a deal ticket reflectingthe priced, matched particular pair of counter electronic trade orders.22. The system of claim 19, wherein a deal ticket is issued for thematched particular counter electronic trade orders which have beenpriced.
 23. The system of claim 19, wherein a trading entity is informedwhen one of the received electronic trade orders is matched or partiallymatched.
 24. The system of claim 19, wherein a trading entity amends thequantity of one of the received electronic trade orders associated withthe trading entity.
 25. The system of claim 19, wherein the receivedelectronic trade orders are first received electronic trade orders, thetrading period is a first trading period and the pricing information isa first pricing information, and after an end time of the first tradingperiod, the system further comprising: the arbitrator computer beingfurther configured to receive a second plurality of electronic tradeorders, each second electronic trade order being associated with asecond trading period having a start time and an end time, each of theplurality of second electronic trade orders specifying a quantity to buyor sell but not a price therefore; the arbitrator computer being furtherconfigured to match two or more of the second electronic trade orderscounter to each other based on quantity but not price during the secondtrading period; the arbitrator computer being further configured tocancel, automatically without user intervention, all of the secondplurality of electronic trade orders associated with the second tradingperiod that were not matched during the second trading period; and thearbitrator computer being further configured to apply, after the endtime of the second trading period, a price to the second electronictrade orders that were matched during the second trading period basedupon second pricing information received from the outside source. 26.The system of claim 25, wherein the first and second trading periodstake place in a single trading day.
 27. An apparatus comprising: anarbitrator computer of a plurality of arbitrator computers, thearbitrator computer associated with a credit manager computer of aplurality of credit manager computers, wherein the associated creditmanager computer is located in a same location as the associatedarbitrator computer so as to provide low network latency between a timean electronic trade order is transmitted to and received by theassociated arbitrator computer and a time that a match is made by theassociated arbitrator computer, each of the plurality of credit managercomputers having stored therein a credit matrix of a plurality of creditmatrices storing data indicative of credit extended between a pluralityof trading entities and configured to receive an electronic trade ordercounter to another electronic trade order previously received by thearbitrator computer associated therewith, forward the receivedelectronic trade orders to the credit manager computer associatedtherewith, and wherein the associated credit manager computer accessesthe stored credit matrix to determine whether, for the receivedelectronic trade orders, trading entities associated therewith have apredetermined level of credit and, based thereon, the arbitratorcomputer matches the received electronic trade orders only when theassociated credit manager computer has determined that the tradingentities associated therewith have a predetermined level of credit.